Pivots OUTSIDE the iDWT optimization space after two consecutive
research-arc washes (v10.24 + v10.25, both confirmed on M2 + Swift
release lever-ceiling). Adds JP3DDecoder.preWarm + JP3DROIDecoder.preWarm
as thin convenience wrappers around the existing J2KDecoder.preWarm
(v5.28.0). Same one-shot Metal init savings, discoverable from the
JP3D module surface.

V10_26_JP3DPreWarmProfile (M2 release, mr_3d_small 128×128×16 LCG
JP3D fixture):
  First decode in process     : 28.26 ms  (cold; includes Metal init)
  First after preWarm()       : 14.60 ms
  Warm median (5 trials)      : 14.33 ms
  Cold-start savings          : −13.93 ms  (clears 3 ms gate)

Savings are CONSTANT per process (one-shot init cost) so they're
most visible on small-volume JP3D decodes where the warm decode
wall itself is short. For consumers doing one-shot JP3D decodes
(e.g., a DICOM viewer opening one study), this is a real-world
latency win delivered through a discoverable API.

Architecture: 2-line static functions in JP3DDecoder.swift +
JP3DROIDecoder.swift, each delegating to
J2KDecoder.preWarm(includeWarmupDispatch:). JP3D shares
J2KMetalSession.processShared via per-slice 2D codec delegation —
the savings flow automatically; v10.15.0 just makes the entry
point discoverable from `import J2K3D` alone.

Validation:
  - V10_26_JP3DPreWarmProfile 1/1 PASS (cold-vs-warm A/B + verifies
    JP3DDecoder.preWarm wires through correctly)
  - swift test --filter JP3D regression 520/520 PASS
  - Mandatory commit gate (release mode) 7/7 PASS

API surface — additions only:
  public static func JP3DDecoder.preWarm(includeWarmupDispatch:Bool=false) async
  public static func JP3DROIDecoder.preWarm(includeWarmupDispatch:Bool=false) async

No removals, no signature changes, no perf change on warm paths.
Codestream bytes byte-identical to v10.14.0. MINOR per RELEASING.md
— additive public API for discoverability + measured cold-start
savings on the JP3D corpus.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>